Mapping manual/Lighting
In this tutorial we're going to discuss concepts and technical stuff about lighting. Unlike newer games, OA has a static lightmap. Shadows aren't cast in real time; they are pre-calculated during the compile of the level.If you run a level in /devmap mode and then type /r_lightmap 1 at the console, you will see the level's lightmap. The geometry, apart from non-lightmapped shaders, will be white, with the shadows, light and colour burnt into it clearly visible. /r_lightmap 0 returns the map to normal. This lightmap is rendered onto the textures you apply to your geometry, so in a way, all textures in Q3 are blended shaders.LevelDK 4: lighting and curves Real time or dynamic lighting isn't also possible in OA, but Q3map2 give us the option of 'faking' dynamic lighting through shader trickery.LevelDK 6: faking dynamic lighting Practical examples and tips on how to use lighting (including the above) can be found in the Advanced lighting page. Why care for lighting? The best answer to this question comes from Sjoerd "Hourences" De Jong:Lighting in game environments by Hourences :: "Lighting is one of the most important and influential elements in environments. It has the power to make or break the visuals, theme and atmosphere. Lighting is often forgotten or underestimated. Designers often add it quickly and without much love. While in the past that was partially excusable by the weak hardware and game engines, these excuses just won't hold up anymore. Lighting is just as important as geometry. Without lighting there is no environment but just a group of 3 dimensional objects. Lighting has the capacity to bring life to a group of objects and take them to the next level of quality. Its purpose goes further than just giving the players the ability to see where they are going. It creates atmosphere. It makes places look scary/cozy or warm/cold. It augments the three dimensional feel of objects and it creates composition and balance to lead the player's eyes around. Yet considering all of that there is a very large group of games and levels out there which use nothing more than white ambient lighting everywhere." The LIGHT stage This is the compilation stage where the lightmaps are generated for every world surface in the map. It has no effect on bsp, hints, vis or r_speeds.SmallPileOfGibs's Q3map explanation The Q3map -light algorithm creates a lightmap pixel for every 16 game world units on a brush, and every 20 units on a patch, stored in 128*128 pages. The lightmaps are 24bit RGB, and are blended with the textures by multiplying the lightmap RGB values with the RGB values of the texture. All lightmap pixels start pure black (RGB 0 0 0). A straight line is traced from the center of each lightmap pixel towards the origin of each point light source. The distance between the pixel and the light source decides the brightness the light adds to the RGB values of that pixel. If the line is blocked by any visible non-transparent brush, the light source does not have any effect on the lightmap pixel. The time taken by the LIGHT stage is proportional to the number of lightmap pixels multiplied by the number of point light sources. The surface lights are subdivided using the q3map_lightsubdivide value (default 64), creating a point light source on the surface every 64 units. These are used in the light calculations in the same way as other point light sources. Light types There are several ways to create light emitting objects.GTKR manual Lights and lighting Entity lights The simplest is to place a light entity into your map. By default it has got value of 300 ("light" "300") and emits white light.When you create a new light entity, an editor dialog box may propose the same value you used last time you added one. If you think about the light value as the wattage for an old-style incandescent light bulb, you are not far off target. Read below for more info. Shader lights Shaders can be made to emit light from a texture. The amount of light that they give off is determined by two factors: the size of the texture and the value given for its q3map_surfacelight parameter. Sky shaders are a subset of this. Usually, the color of a shader light is given by the average color of the texture specified with q3map_lightimage parameter, however Q3MAP2 added q3map_lightrgb keyword to manually specify shader light color; sky shaders can also cast the light of a "sun" (or more) with a manually-specified color. How to create light-emitting shaders is covered in the shaders page. Ambient light Let's give a look to the ways to add some light all around the map, to avoid black spots: ambient, _minlight, _floodlight and "radiosity". Ambient light (key "ambient"/"_ambient") is a property of the map's worldspawn entity. By assigning a number value to the ambient key, the overall lighting level of the map is raised. This has the tendency to flatten the difference between light and shadow. Ambient light usage isn't recommended. You may prefer to use "_minlight" instead, which raises the lighting level-wise, but keeps the light values of each entity/sky/shader intact.Difference between "ambient" and "_minlight" should roughly be something like this: in case you have four points (A, B, C, D) of the map which are illuminated like 0, 4, 10, 50 respectively, and then add "ambient 5", they will result as A 5, B 9, C 15, D 55; if you use "_minlight 5" instead, they will result as A 5, B 5, C 10, D 50. "_minlight" is not supported by the old Q3MAP used by Q3Radiant. In case you decide to use one of them, you have to also specify "_color" key, which specifies the color of the light. In any case, abuse of this "ambient" and "_minlight" (and in most cases, also use) isn't recommended. The best thing to do regarding lighting is to light the level oneself, placing lights where needed and creating sky shaders with appropriate parameters. There are also a few other tricks to illuminate more your map, which look much more "natural" than ambient or _minlight, such as "_floodlight" and "radiosity" (the latter one is not a worldspawn property, but the mix of bounce and other Q3MAP2 compiling parameters): you can refer to Fake indirect lighting page for more infos about "floodlight" and "radiosity". You may like them more than ambient and _minlight, although they have their limits, too. Note -'' Q3MAP2 "LIGHT" compiling phase options, such as "-bounce ", can notably change illumination results: see also ''Mapping manual/Compiling and packaging. Using compile options like bounce can help having some light also is surfaces which do not directly "see" a light source (having boxes with a pitch black side inside a well-illuminated room would look strange). The "light" entity Non-displayed light entity. The default condition emits white light in all directions at a value of 300 ("light" "300"). The apparent brightness of the light is modeled on "real world" physics, so the falloff in brightness willl be an inverse square of distance from the source. It can be colored. It can be targeted on an info_null entity to make a spotlight. GTKR manual The "light" entity Keys * light: value of light intensity (default 300). If you think about the light value as the wattage for an old-style incandescent light bulb, you are not far off target. * _color: weighted RGB value of light color (default white - 1 1 1). * target: point this to an target_position, info_null or info_notnull to create a spotlight effect, instead of illuminating in all directions. * radius: sets radius of light cone for spotlights (default 64) in game units. Radius measurement is made at the targeted entity. Light must target an info_null entity (info_nulls are only used by the compiler and need not be "remembered" by the game engine during play). Spawnflags * LINEAR: light falloff will be linear instead of inverse square of distance from source. Linear fall off will not make much difference on low value lights. Useful on high value lights where the light travels long distances. Coloring lights There are several ways a light entity can be colored: * CTRL + K: With the entity window open, select a light entity in either the map or camera window. Press CTRL + k. This brings up the windows color selector. Select a color and choose "OK". The editor automatically normalizes the light colors. * Sample Texture: Select the light entity. Select a texture in either the texture window or the camera window. Hit SHIFT + middle mouse button. * Manual Entry: Type in the value for the key _color as a 3 numbers between 0 and 1 (inclusive). * Copy Existing: Select another light entity whose color value the user would like to duplicate. In the editor window, lef click on the key "_color". Now select the light entity to be colored. Hit ENTER. If the "Light drawing" preference is selected (under Preferences), the editor shows the light entities as diamond shaped pieces the color of the light they cast. If not, they are light yellow green cubes. Color normalization Colors are expressed in RGB (red-green-blue) values, but not going from 0 to 255 like many programs do: their range is from 0.0 to 1.0. Hence, if you know an RGB color on 255-scale as R 241, G 55, B 100, you have to "normalize" those values by calculating 241/255=0.94509, 55/255=0.21568 and 100/255=0.39215. Notes Further reading * Mapping_manual/Advanced_lighting * Mapping_manual/Compiling and packaging#The Light stage * High resolution lightmaps by 0kelvin * Fake indirect lighting by 0kelvin (Floodlight, Radiosity) * Fixing overburned pixels by 0kelvin External Links * Wikibooks' Lights * Worldspawn archive's Playing around with lights * WeMakeMaps.com Basic Lighting * WeMakeMaps.com Adding lights to models * WeMakeMaps.com Sky Lights * WeMakeMaps.com Ambient light